home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL95.LZH / letters_fj / text0021.txt < prev    next >
Encoding:
Text File  |  1995-10-04  |  8.6 KB  |  206 lines
  1. Hi again,
  2.  
  3. > Laurent thought about MOOD. Good idea, heh?
  4.  
  5. Yes, it sure is.  ;-)
  6.  
  7. > >No, but it'd be more comfortable to have at least a working title,
  8. > >especially for discussions on newsgroups etc.
  9. > OK, let's call it MOOD for short.
  10.  
  11. I think a two word title would be better, but for the time being it's not
  12. bad at all.
  13.  
  14. > Exactly. So the program should be more or less the same, it's what you
  15.  
  16. Yes, I believe so.
  17.  
  18. > think? And Laurent seems to be enthousiastic about the improvements he can
  19. > bring. So...
  20.  
  21. He's back now, by the way. I exchanged some email with him today.
  22. I think we should set up some kind of mailing list to make the discussions
  23. easier, especially if more people get involved. You don't happen to know
  24. anything about how to do that, do you?
  25.  
  26. > In fact, I don't know how he plans to do it. But I have to try
  27. > independantly, just to see what can be done with the 68030 alone.
  28.  
  29. Yes, I've been thinking about that myself.  ;-)
  30.  
  31. > You mean that the texture mapping is standard enough stuff and that the real
  32.  
  33. Perhaps not standard, but at least pretty short and relatively simple.
  34.  
  35. > improvements will be to decide in the fastest possible way what to draw, and
  36. > what not to draw?
  37.  
  38. Yes.
  39.  
  40. > So you're in computers to the throat!
  41.  
  42. I guess you could say that.
  43.  
  44. > lot more "classical" litterature. SF is fun, but not so interesting...
  45.            ^^^^^^^^^^^
  46. Anything special you could recommend? I'm out of books at the moment.
  47.  
  48. > I was very good at fencing when I was a kid, but I quit when I was 17. I
  49.  
  50. Well, so far I have no plans on quitting so hopefully I'll be pretty good
  51. in 17 years or so...   ;-)
  52.  
  53. > often play with the idea of digging my old sword out of the attic.
  54.  
  55. What type of weapon did you use? Foil?
  56. I can't find any literature that mentions much about anything other than
  57. that, but I'm learning epee (Really strange name that. In Swedish we
  58. use the same word as for rapier), which needs quite another type of
  59. tactics it seems.
  60.  
  61. > Is Rowdraw used only when drawing floors? I think our program will certainly
  62.  
  63. Yes, but it's pretty fast since it just throws out a bunch of bytes at
  64. consecutive addresses.
  65.  
  66. > >of large arrays, though, which would not have fit. Fortunately, I believe
  67. > >I have found a way to get rid of almost all of that.
  68. > What is it? And has all this data to be kept at the same time?
  69.  
  70. Well, originally DVIEW caclulated all the horizontal and vertical runs to
  71. be drawn before actually writing a single pixel. It then started with
  72. the floors/ceilings and when all those were drawn did the walls.
  73. Apart from some special cases (that I don't think should occur, but I
  74. can't convince DVIEW of that) it is, however, possible to for every line
  75. segment checked, draw it and the corresponding floor and ceiling. That
  76. way only a small part of the previous tables has to be kept.
  77.  
  78. Take a look at how the drawing occurs in 'F'/'W' mode with single step.
  79. The image is built up in a very strange way, but nothing is drawn twice
  80. (I even XOR everything to show that absolutely clear) except for the
  81. strange special cases I've mentioned.
  82.  
  83. > Anyway, I have to take a serious look at the source of DVIEW. I haven't had
  84. > the time to do it yet.
  85.  
  86. Be prepared that it takes a while to come to grips with it. The single step
  87. drawing functionality helps quite a bit.
  88.  
  89. > Yes, because there is probably no other way to draw them than back to front.
  90. > So you have to keep track of the coordinates of the transparent polygons of
  91. > the ssectors. Is that it or am I completely out of the point?
  92.  
  93. I've not given any thought to transparent walls yet, but the problem is
  94. close to what you say (if I understood you correctly).
  95. Consider the problem of drawing a sprite behind a low pillar some way 'into'
  96. the picture:
  97. - It's more or less impossible to draw the sprite before or
  98.   during the drawing of floors, ceilings and walls since there would have to
  99.   be a lot of masking etc going on.
  100. - The legs of the monster are covered by both the walls and the top surface
  101.   of the low pillar.
  102. Now, without having all the coordinates for the pixels that constitue our
  103. pillar, we can't help drawing the monster partly on top of it, which 
  104. needless to say would look _bad_.
  105. Of course different parts of the monster could be covered by different
  106. pillars and 'stalagtites' as well as walls from the sides...
  107.  
  108. > No no! I think you're right. We have to keep in mind that we have sprites to
  109.  
  110. Ah, this really is difficult. Without bothering about the sprites we could
  111. probably make the engine quite a bit faster, but putting them in afterwards
  112. _could_ be _very_ difficult. As I've mentioned elsewhere, I think we'd
  113. need all the pixel coordinate info to do the sprites right as well...
  114.  
  115. > draw. And do the transparent textures bring problems?
  116.  
  117. I've not really considered those yet. Are they really that common in DOOM?
  118. There are none in Jaguar DOOM and it doesn't seem to matter much, but then
  119. those levels have been redesigned, which obviously is not an option for us.
  120.  
  121. > Yes, I thought the right way to do it was to draw all the solid walls of a
  122. > ssector, and then, for each transparent wall, to look in the BSP which
  123. > ssector is behind it, and draw this sector, clipped by the transparent wall.
  124.  
  125. You wouldn't really have to consider the transparent wall at while drawing
  126. what is behind it, I think. Just draw it on top afterwards.
  127.  
  128. > Then, when returning, draw the transparent or semi transparent wall. So you
  129. > have to pile the coordinates of the transparent walls. Couldn't this data be
  130.  
  131. You could do that for all walls, transparent or not. As I've said, the
  132. modifications I've done for memory efficiency draw walls one at a time
  133. without every drawing a pixel twice. So the order (front to back or the
  134. reverse) of the drawing is actually unimportant.
  135. _But_, you would need to keep all the coordinate information I optimized
  136. away if you were going to remember what wall etc you should draw on top.
  137. Doing it only for transparent walls might be workable if they really are
  138. as uncommon as I believe.
  139.  
  140. > used to draw the sprites, also? Or am I once more completely out of the
  141. > question?
  142.  
  143. If there's nothing wrong with my reasoning above (I guess you'll have to
  144. spend some hours with the DVIEW sources before you can find out), it 
  145. wouldn't work (without severe memory overhead) since the sprites are so
  146. many.
  147.  
  148. By the way, I'm not sure what definitions you use for 'tranparent' and
  149. 'semi-transparent' walls. That might be a communication problem.
  150. What I mean (and I only use one of the terms) is a wall that has a texture
  151. with transparent holes in it. Most windows etc only have walls at the top
  152. bottom and thus don't need any kind of transparency. Diagonal windows and
  153. cell bars that are in some places do, however.
  154.  
  155. > >I've heard that SNES DOOM has no floor or ceiling. I'll try that out.
  156. > Well, even so, you've got to draw a filled polygon...
  157.  
  158. No, you've got to draw a bunch of horizontal lines which is much easier.
  159. It would even be enough to clear the screen before you start drawin, but
  160. that might be slower.
  161.  
  162. > >I've spent far too much time with DVIEW, so I'm going to leave it as it is
  163. > >for now. It simply refuses to do as I want...
  164. > What do you mean?
  165.  
  166. It's those display glitches that I can't get rid of. I've been _sure_ so
  167. many times now that I've got rid of them, only to find out that my new
  168. 'fixed' code don't improve things at all or causes major havoc all over
  169. the place...
  170.  
  171. I guess if I had the patience to sit down and work out all the checks from
  172. the ground up I could get it right, or at least find out why it won't work.
  173.  
  174. > >For good examples of the bugs, go into the room directly on the left
  175. > >in the first level and look at the top of the stairs. The problem there
  176. > >is that the wall outside is drawn on top of rest of the room. The
  177. > >secret door near the end of the level is an example of the 'transparancy'.
  178. > >If you can fix those bugs, I'd be very happy.
  179. > I'll also try to understand this.
  180.  
  181. ;-)
  182.  
  183. > OK.
  184. > Well, Bye. I'll keep you informed. But I have to admit I'm very impressed by
  185. > the speed at which you achieved so much.
  186.  
  187. I haven't really _achieve_ that much. The changes to DVIEW are not very
  188. extensive really, but I guess I've got a rather thorough understanding
  189. of how to do the 3D environment. That's not to say that there's not parts
  190. that can be done quite differently as I guess this letter has shown.
  191.  
  192.  
  193. Ooops, I just got a warning that the system is going down in a couple of
  194. minutes so I guess I should send this off. I've not reread it very
  195. carefully, but I hope it's more or less coherent.
  196.  
  197. Regards,
  198. Johan
  199.  
  200. -- 
  201.   Chalmers University   | Why are these |  e-mail:   d8klojo@dtek.chalmers.se
  202.      of Technology      |  .signatures  |            rand@cd.chalmers.se
  203.                         | so hard to do |  www/ftp:  rand.thn.htu.se
  204.    Gothenburg, Sweden   |     well?     |            (MGIFv5 and QLem)
  205.  
  206.